On Posteriori Integration of Software Tools

This paper tries to define and exampJify the concept of "integration" in the context of soflware development support environments. TIle benefits of tight integration are discussed, together with different approaches on how to achieve this properlY under the constraint of having to include existing software components and tools. The paper finally reports on the initial experience gained in building an Ada programming support environment according to those principles. 1. The Role of Integration Much hope is today focussed on the use of tools as a way increasing productivity in software development, shown, for example, by the rapidly growing activity under the label "CASE". While a substantial market of tools, supporting various parts of the software lifecycle, indeed exist, few people would claim that a corresponding major productivity breakthrough has occurred. In this paper, we will focus on what might be the major obstacle before substantial gains can be shown the lack' Of integration. The basic argument is that the semantic loss and overhead imposed by moving between tools that don't know about, and contribute to, each other, is so big that it cannot be bypassed. Another aspect of the problem is that the tasks perfonned during software development never are so phased and isolated from each other, as the body of existing tools seem to imply. Infact, software development is never is truly "automatic", and the role of tools is therefore most often in providing the user with the infonnation he needs, and doing so WiUl short response time and without requiring him to engage in errorprone or context breaking dialogues with different other tools. The infonnation needed often spans over phases, obvious examples being the need for accessing requirements documents, and design descriptions, in direct connection to programming and maintenance. In building support systems, the approach has often been to concentrate on selecting the "right" functions, quite independently of each other. While this decomposition-oricnted approach is easier to deal with, both from a teclmical and project administrative point of view, it usually fails to recognize tile large potential of cross-service cooperation, and the obvious fact that the value and usefulness of a service always is relative to its cost, tile latter which has tluec components: (I) The cost of activating a service in tcnns of finding it and providing tile light parameters. (2) The cost, in waiting time, for tile user while the computer is working. (3) The cost of finally"utilizing and assimilating the result of the service in tile context where the user needs it. • We call the sum of those costs the tl4rnaround time, and the purpose of our work is to minimize it. Observe that we discuss not only the turnaround time of currenUy identified atomic services, but Ule minimization of the cost for any typical pattern of work. For example, if the looking up of an imported interface is a common task, one could expect its turnaround time to be large in a traditional environment since it probably involves leaving an editor to go out in a file system, explicitly locating a file holding the interface, studying the interface and remembering it, and then returning to the first point of editing without any oUler result than what could be memorized during the break. Given the above view of the goal, it is clear Ulat imegratioll is a a key issue. The first and third components of the turnaround cost can obviously be very effectively attacked by utilizing context information making one tool explicitly utilize knowledge about the detailed state and context of the other tool. As will be described later, it also turns out that much less CPUcycles are consumed in a carefully built integrated system, making it effective in reducing even the second cost component. 1.1. A Definition of Integration Despite Um fact that integration is often mentioned as a highly desirable property of support environments, it still lacks a more precise cOlnmonly agreed on definition, and most publications never even try to be more explicit on the nature and meaning of the concept. However, as a concluding remark on the subject of integration, we propose the following: In Ule context of software development environments, we discuss integration in terms of three characterizing properties of tools: IIIlijonllity, communicational ability, and openlless of representation. Each of UlOse are explained below together with examplcs. 1.1.1. Uniformity. Measures the degree to which different tools behave in a similar way in similar situations. This spans from reusing Ule same abstract concepts whcnever possible, to the unification of syntactical aspects of the user interface. The word external imegratioll has frequenUy been used to denote the latter part of this spectrum. Examples: * Use of Ule same command language and line editing conventions. * Use of the same conventions for managing windows and menues. * Use of the same user interaction style, such as pointing-at-object, iconization, parameter defaults, and command result reporting. * Use of the same editing, viewing, and searching tool for all texts. * Use of the same conceptual model for representation of data. In a Entity-RelationshipAttribute based environment it would be natural to view most data in terms of typed, attributed, directed graphs. Other environments present other conceptual models, like strings, lists, and (mathematical) relations. * Use of similar operations on diffcrent data represented using the same model. * Use of Ule same definitions of concepts; such as version, configuration, dependency, inheritance, relation, access privilege, transaction, icon, data key, Iype, etc. (